Object oriented programming is used to design computer software that is easy to create, cost effective to modify, and reusable. Object oriented programming objects are pieces of computer software that include object data and information and provide services through "object methods" (also called object operations or object functions). The object methods typically operate on private data such as instance data or object state data that the object owns. A collection of objects make up an "object class," which is sometimes called an "object type." An object class acts as a template that describes the behavior of sets of objects. An object's implementation is typically encapsulated, and is hidden from public view. Object private instance data can only be accessed by object methods private to the object class. Object public instance data is accessed through a public object interface.
The Component Object Model (COM) and Distributed Component Object Model (DCOM) are models used for object-oriented programming. The COM and DCOM specify how objects interact and communicate within a single application, a distributed application or between applications (e.g., client/server applications) by defining a set of standard interfaces. Object interfaces are groupings of semantically related functions through which a client application accesses the services of a server application.
Object Linking and Embedding (OLE), such as OLE Version 2 and ActiveX Controls by Microsoft Corporation of Redmond, Wash. are based in part on the Component Object Model. They allow the creation of objects which operate on object data through defined object interfaces, rather than operating on the applications responsible for the data. ActiveX controls are based in part on OLE technologies. An ActiveX control is an object with properties such as color, shape and event notifications (e.g., "someone has clicked on me"). OLE and ActiveX controls are known to those skilled in the art.
An object designer is a top-level software component that runs within a dedicated design environment. Object designers provide features which can be used and customized by developers to develop objects or classes of objects for use in their applications, components, etc. The Forms object class (i.e., graphical form .FRM) provided with the Visual Basic programming language by Microsoft Corporation is one type of object designer.
For example, the supplier of a large management information system (MIS) application might develop an object designer that contains forms and controls unique to its databases. Database programmers at customer sites can then use the designer to design local applications that access the database and perform specific query and update tasks.
As another example, a multimedia design package for object-oriented applications used on a computer network like the Internet or an intranet might include an object designer that allows developers to edit text and graphics. Using such a designer, a developer could create a "Happy Birthday" object that contains the text "Happy Birthday!", a sound clip of a birthday song, and a graphical image of a cake, with graphical candles blazing.
An object designer manages the design-time aspects of an object by visually designing objects as well as managing the run-time aspects of the object it designs. The object designer creates and destroys windows (e.g., windows within one of the windowed operating systems by Microsoft Corporation), handles the user interaction, and controls the look and feel of the designer within the visual host environment. It also provides information about the objects in the designer and allows property browsers, wizards (e.g., help wizards), and other tools to manipulate the objects.
Using an object designer, developers can create and manipulate objects and modify the properties of these objects. The customizations become part of the data used at run-time in an executable application making use of these objects. In the current art, a run-time object which makes use of the objects are actually another instance of the object designer itself. Thus, the object designer is a monolithic object designer which must support both design-time and run-time behaviors. Also, the data used at run-time is the same data that is used at design-time when loading the object for further manipulation.
As is known in the art, an object designer class is used to create a new instance of a design-time object. Customizations and property changes made in the design-time object are saved in a storage medium for later use. When the customizations and property changes are saved, a developer can later make further modifications without keeping the design-time object loaded in memory. A new instance of the design-time object is created and re-initialized from the data saved in storage. At run-time, the object designer class is used to instantiate a run-time object using the data saved in storage which includes a design-time object.
Developers can also write code to further customize and manipulate the properties, methods, and events of the run-time objects they create. This customization code is not managed by the object designer, but rather is managed by the development environment itself.
There are several problems associated with an object designer class which implements both run-time objects and design-time objects. The design-time object and run-time object will often differ in functionality. For example, the design-time object displays a grid for laying out object controls, while the run-time object has no need for such functionality. As another example, the design-time object is visible (e.g., is it used to design an object with a user interface and contains components like grid s, etc.), while the run-time object may be invisible (e.g., used to query a database) and not require a user interface during run-time. As a result, a library, such as a dynamic link library (.DLL) used to implement the object designer class is significantly larger than it needs to be since a large portion of the design-time functionality (e.g., the design-time user interface used to create the object) is not used at run-time. The presence of unnecessary design-time code in a library used at run-time significantly impacts the resources of a computer the run-time object is executed on. The run-time object will require more time to load into memory and more time to execute since it contains design-time code which is not be used at run-time.
Another problem associated with an object designer class which implements both run-time objects and design time objects is that an originating developer who distributes the object library (because it is required to create run-time objects) under some agreement (e.g., a license) is also distributing the design-time functionality. A receiving developer who receives the object designer can potentially create new run-time applications using the embedded design-time functionality of the object designer library. This use of the design-time objects might be beyond the scope of the distribution agreement intended by the originating developer who distributed the object Thus, the originating developer could potentially lose revenue or other benefits that were negotiated under the original distribution agreement.
Yet another problem is that run-time objects created the object designer have to be the same object class as the design-time objects. This is because the object designer is the object class implementing both the run-time objects and the design-time objects. This limits the number object classes for which run-time objects can be created with object designers.
Yet another problem is that the data needed to instantiate run-time objects is saved in the same persistence (i.e., non-volatile) format as the design-time objects. It is often desirable to save the run-time data in a persistence format different from the design-time objects. For example, a graphical form at design-time may have a design grid setting. When saving the form information at design-time, it is desirable to save the grid setting in a persistence format so a developer does not have to reset the grid setting each time the graphical form is accessed. However, the grid settings are not used in the run-time object since the form layout cannot be changed at run-time. As a result, the run-time object persistence state contains design-time information which is not needed. This makes the run-time persistence state information much larger than it needs to be since the run-time object persistence state cannot be separated from the design-time persistence state information. When the run-time object is downloaded via the Internet, an intranet or other computer network, unnecessary design-time persistence information is also downloaded. This significantly increases the download time and the associated delay for a user.
Yet another problem is that when run-time object data and design-time object data are the same, the run-time data cannot be optimized for maximized performance since the design-time object data cannot be removed. In a typical programming environment, a run-time application is optimized to maximize its run-time performance when it is compiled by a compiler into an executable application (e.g., in C++ the source file .CPP is compiled into an optimized executable .EXE file).
Yet another problem is that object designers are typically inseparable from the application framework for which they were designed. Object designers built into a particular design tool have object properties unique to the design tool and can not be used directly by other design tools. This limits the portability of the object designers to other development environments.
In accordance with an illustrative embodiment of the present invention, certain of the foregoing problems are overcome. A method of designing objects with a componentized object designer is used. The componentized object designer includes an object designer class which is used to create a design-time object, and one or more separate run-time object classes. The method includes using a componentized object designer to create an instance of a design-time object. The design-time object is used to create multiple application specific objects. The object properties, object methods and object events of the application specific objects are manipulated with the design-time object. A run-time object is created with the design-time object by selecting one or more of the manipulated application specific objects. This method allows the creation of a run-time object different from the design-time object and a run-time object which comprises an object class different from the run-time object.
The componentized object designer in the present invention can also be used to create run-time files in a pre-determined persistence format usable by applications other than the componentized object designer. The run-time files created are in a format that is different than that normally created by the componentized object designer for run-time use. For example, the componentized object designer may created run-time files in Hyper Text Markup Language (HTML) format that are used by an Internet browser. The Internet browser can then view and/or manipulate the run-time files created in HTML by the componentized object designer.
To address the licensing issue, an exemplary embodiment provides an environment in which a design-time object is used to create a run-time object. A license key is then requested from the object designer for the run-time object. This key is then embedded into the run time object.
The foregoing and other features and advantages of an illustrative embodiment of the present invention will be more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.